<div class="tmd-doc">
<h1 class="tmd-header-1">
Value Parts
</h1>
<p></p>
<div class="tmd-usual">
The articles following the current one will introduce more kinds of Go types. To easily and deeply understand those articles, it is best to read the following contents in the current article firstly before reading those articles.
</div>
<p></p>
<h3 class="tmd-header-3">
Two Categories of Go Types
</h3>
<p></p>
<div class="tmd-usual">
Go can be viewed as a C-family language, which can be confirmed from the two previous articles <a href="pointer.html">pointers in Go</a> and <a href="struct.html">structs in Go</a>. The memory structures of struct types and pointer types in Go and C are much alike.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
On the other hand, Go can be also viewed as a C language framework. This is mainly reflected from the fact that Go supports several kinds of types whose value memory structures are not totally transparent, whereas the main characteristic of C types is the memory structures of C values are transparent. Each C value in memory occupies <a href="memory-block.html">one memory block</a> (one continuous memory segment). However, a value of some kinds of Go types may often be hosted on more than one memory block.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
Later, we call the parts (being distributed on different memory blocks) of a value as value parts. A value hosting on more than one memory blocks is composed of one direct value part and several underlying indirect parts which are <a href="pointer.html#references">referenced</a> by that direct value part.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
The above paragraphs describe two categories of Go types:
</div>
<table class="tmd-table">
<tr>
<th>
Types whose values each is only hosted on one single memory block
</th>
<th>
Types whose values each may be hosted on multiple memory blocks
</th>
</tr>
<tr>
<td>
<div class="tmd-usual">
<img src="res/value-parts-single.png" class="tmd-media"/>
</div>
</td>
<td>
<div class="tmd-usual">
<img src="res/value-parts-multiple.png" class="tmd-media"/>
</div>
</td>
</tr>
<tr>
<td>
<div class="tmd-base tmd-align-center">
<div class="tmd-usual">
boolean types<br/>numeric types<br/>pointer types<br/>unsafe pointer types<br/>struct types<br/>array types
</div>
</div>
</td>
<td>
<div class="tmd-base tmd-align-center">
<div class="tmd-usual">
slice types<br/>map types<br/>channel types<br/>function types<br/>interface types<br/>string types
</div>
</div>
</td>
</tr>
</table>
<p></p>
<div class="tmd-usual">
The following Go 101 articles will make detailed explanations for many kinds of types listed in the above table. The current article is just to make a preparation to understand those explanations more easily.
</div>
<p></p>
<div class="tmd-usual">
Note,
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
whether or not interface and string values may contain underlying parts is compiler dependent. For the standard Go compiler implementation, interface and string values may contain underlying parts.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
whether or not functions values may contain underlying parts is hardly, even impossible, to prove. In Go 101, we will view functions values may contain underlying parts.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
The kinds of types in the second category bring much convenience to Go programming by encapsulating many implementation details. Different Go compilers may adopt different internal implementations for these types, but the external behaviors of values of these types must satisfy the requirements specified in Go specification.
</div>
<p></p>
<div class="tmd-usual">
The types in the second category are not very fundamental types for a language, we can implement them from scratch by using the types from the first category. However, by encapsulating some common or unique functionalities and supporting these types as the first-class citizens in Go, the experiences of Go programming become enjoyable and productive.
</div>
<p></p>
<div class="tmd-usual">
On the other hand, these encapsulations adopted in implementing the types in the second category hide many internal definitions of these types. This prevents Go programmers from viewing the whole pictures of these types, and sometimes makes some obstacles to understand Go better.
</div>
<p></p>
<div class="tmd-usual">
To help gophers better understand the types in the second category and their values, the following contents of this article will introduce the internal structure definitions of these kinds of types. The detailed implementations of these types will not be explained here. The explanations in this article are based on, but not exactly the same as, the implementations used by the standard Go compiler.
</div>
<p></p>
<h3 class="tmd-header-3">
Two Kinds of Pointer Types in Go
</h3>
<p></p>
<div class="tmd-usual">
Before showing the internal structure definitions of the kinds of types in the second category, let's clarify more on pointers and references.
</div>
<p></p>
<div class="tmd-usual">
We have learned <a href="pointer.html">Go pointers</a> in the article before the last. The pointer types in that article are type-safe pointer types. In fact, Go also supports <a href="unsafe.html">type-unsafe pointer types</a>. The <code class="tmd-code-span">unsafe.Pointer</code> type provided in the <code class="tmd-code-span">unsafe</code> standard package is like <code class="tmd-code-span">void*</code> in C language.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
In most other articles in Go 101, if not specially specified, when a pointer type is mentioned, it means a type-safe pointer type. However, in the following parts of the current article, when a pointer is mentioned, it might be either a type-safe pointer or a type-unsafe pointer.
</div>
<p></p>
<div class="tmd-usual">
A pointer value stores a memory address of another value, unless the pointer value is a nil pointer. We can say the pointer value <a href="pointer.html#references">references</a> the other value, or the other value is referenced by the pointer value. Values can also be referenced indirectly.
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
If a struct value <code class="tmd-code-span">a</code> has a pointer field <code class="tmd-code-span">b</code> which references a value <code class="tmd-code-span">c</code>, then we can say the struct value <code class="tmd-code-span">a</code> also references value <code class="tmd-code-span">c</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
If a value <code class="tmd-code-span">x</code> references (either directly or indirectly) a value <code class="tmd-code-span">y</code>, and the value <code class="tmd-code-span">y</code> references (either directly or indirectly) a value <code class="tmd-code-span">z</code>, then we can also say the value <code class="tmd-code-span">x</code> (indirectly) references value <code class="tmd-code-span">z</code>.
</div>
</li>
</ul>
<p></p>
<p></p>
<div class="tmd-usual">
Below, we call a struct type with fields of pointer types as a <span class="tmd-bold">pointer wrapper type</span>, and call a type whose values may contains (either directly or indirectly) pointers a <span class="tmd-bold">pointer holder type</span>. Pointer types and pointer wrapper types are all pointer holder types. Array types with  pointer holder element types are also pointer holder types. (Array types will be explained in the next article.)
</div>
<p></p>
<h3 class="tmd-header-3">
(Possible) Internal Definitions of the Types in the Second Category
</h3>
<p></p>
<div class="tmd-usual">
To better understand the runtime behaviors of values of the second category, it is not a bad idea that we could think these types are internally defined as types in the first category, which are shown below. If you haven't used all kinds of Go types much, currently you don't need to try to comprehend these definitions clearly. Instead, it is okay to just get a rough impression on these definitions and reread this article when you get more experience in Go programming later. Knowing the definitions roughly is good enough to help Go programmers understand the types explained in the following articles.
</div>
<p></p>
<h4 class="tmd-header-4">
Internal definitions of map, channel and function types
</h4>
<p></p>
<p></p>
<div class="tmd-usual">
The internal definitions of map, channel and function types are similar:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">// map types
type _map *hashtableImpl

// channel types
type _channel *channelImpl

// function types
type _function *functionImpl
</code></pre>
<p></p>
<div class="tmd-usual">
So, internally, types of the three kinds are just pointer types. In other words, the direct parts of values of these types are pointers internally. For each non-zero value of these types, its direct part (a pointer) references its indirect underlying implementation part.
</div>
<p></p>
<div class="tmd-usual">
BTW, the standard Go compiler uses hashtables to implement maps.
</div>
<p></p>
<h4 class="tmd-header-4">
Internal definition of slice types
</h4>
<p></p>
<div class="tmd-usual">
The internal definition of slice types is like:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">type _slice struct {
	// referencing underlying elements
	elements unsafe.Pointer
	// number of elements and capacity
	len, cap int
}
</code></pre>
<p></p>
<div class="tmd-usual">
So, internally, slice types are pointer wrapper struct types. Each non-zero slice value has an indirect underlying part which stores the element values of the slice value. The <code class="tmd-code-span">elements</code> field of the direct part references the indirect underlying part of the slice value.
</div>
<p></p>
<h4 class="tmd-header-4">
Internal definition of string types
</h4>
<p></p>
<div class="tmd-usual">
Below is the internal definition for string types:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">type _string struct {
	elements *byte // referencing underlying bytes
	len      int   // number of bytes
}
</code></pre>
<p></p>
<div class="tmd-usual">
So string types are also pointer wrapper struct types internally. Each string value has an indirect underlying part storing the bytes of the string value, the indirect part is referenced by the <code class="tmd-code-span">elements</code> field of that string value.
</div>
<p></p>
<h4 id="interface-structure" class="tmd-header-4">
Internal definition of interface types
</h4>
<p></p>
<div class="tmd-usual">
Below is the internal definition for general interface types:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">type _interface struct {
	dynamicType  *_type         // the dynamic type
	dynamicValue unsafe.Pointer // the dynamic value
}
</code></pre>
<p></p>
<div class="tmd-usual">
Internally, interface types are also pointer wrapper struct types. The internal definition of an interface type has two pointer fields. Each non-zero interface value has two indirect underlying parts which store the dynamic type and dynamic value of that interface value. The two indirect parts are referenced by the <code class="tmd-code-span">dynamicType</code> and <code class="tmd-code-span">dynamicValue</code> fields of that interface value.
</div>
<p></p>
<div class="tmd-usual">
In fact, for the standard Go compiler, the above definition is only used for blank interface types. Blank interface types are the interface types which don't specify any methods. We can learn more about interfaces in the article <a href="interface.html">interfaces in Go</a> later. For non-blank interface types, the definition like the following one is used.
</div>
<p></p>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">type _interface struct {
	dynamicTypeInfo *struct {
		dynamicType *_type       // the dynamic type
		methods     []*_function // method table
	}
	dynamicValue unsafe.Pointer // the dynamic value
}
</code></pre>
<p></p>
<div class="tmd-usual">
The <code class="tmd-code-span">methods</code> field of the <code class="tmd-code-span">dynamicTypeInfo</code> field of an interface value stores the implemented methods of the dynamic type of the interface value for the (interface) type of the interface value.
</div>
<p></p>
<p></p>
<h3 id="about-value-copy" class="tmd-header-3">
Underlying Value Parts Are Not Copied in Value Assignments
</h3>
<p></p>
<div class="tmd-usual">
Now we have learned that the internal definitions of the types in the second category are pointer holder (pointer or pointer wrapper) types. Knowing this is very helpful to understand value copy behaviors in Go.
</div>
<p></p>
<div class="tmd-usual">
In Go, each value assignment (including parameter passing, etc) is a shallow value copy if the involved destination and source values have the same type (if their types are different, we can think that the source value will be implicitly converted to the destination type before doing that assignment). In other words, only the direct part of the source value is copied to the destination value in a value assignment. If the source value has underlying value part(s), then the direct parts of the destination and source values will reference the same underlying value part(s), in other words, the destination and source values will share the same underlying value part(s).
</div>
<p></p>
<div class="tmd-base tmd-align-center">
<div class="tmd-usual">
<img src="res/value-parts-copy.png" class="tmd-media"/>
</div>
</div>
<p></p>
<div class="tmd-usual">
In fact, the above descriptions are not 100% correct in theory, for strings and interfaces. The <a href="https://golang.org/doc/faq#pass_by_value">official Go FAQ</a> says the underlying dynamic value part of an interface value should be copied as well when the interface value is copied. However, as the dynamic value of an interface value is read only, the standard Go compiler/runtime doesn't copy the underlying dynamic value parts in copying interface values. This can be viewed as a compiler optimization. The same situation is for string values and the same optimization (made by the standard Go compiler/runtime) is made for copying string values. So, for the standard Go compiler/runtime, the descriptions in the last section are 100% correct, for values of any type.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
Since an indirect underlying part may not belong to any value exclusively, it doesn't contribute to the size returned by the <code class="tmd-code-span">unsafe.Sizeof</code> function.
</div>
<p></p>
<p></p>
<h3 class="tmd-header-3">
About the "Reference Type" and "Reference Value" Terminologies
</h3>
<p></p>
<div class="tmd-usual">
The word <span class="tmd-bold"><span class="tmd-italic">reference</span></span> in Go world is a big mess. It brings many confusions to Go community. Some articles, including some <a href="https://golang.org/doc/faq#references">official ones</a>, use <span class="tmd-bold"><span class="tmd-italic">reference</span></span> as qualifiers of types and values, or treat <span class="tmd-bold"><span class="tmd-italic">reference</span></span> as the opposite of <span class="tmd-bold"><span class="tmd-italic">value</span></span>. This is strongly discouraged in Go 101. I really don't want to dispute on this point. Here I just list some absolutely misuses of <span class="tmd-bold"><span class="tmd-italic">reference</span></span>:
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
only slice, map, channel and function types are reference types in Go. (If we do need the <span class="tmd-bold"><span class="tmd-italic">reference type</span></span> terminology in Go, then we shouldn't exclude any pointer holder types from reference types).
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
references are opposites of values. (If we do need the <span class="tmd-bold"><span class="tmd-italic">reference value</span></span> terminology in Go, then please view reference values as special values, instead of opposites of values.)
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
some parameters are passed by reference. (Sorry, all parameters are passed by copy, <span class="tmd-bold">of direct parts</span>, in Go.)
</div>
</li>
</ul>
<p></p>
<p></p>
<div class="tmd-usual">
I don't mean the <span class="tmd-bold"><span class="tmd-italic">reference type</span></span> or <span class="tmd-bold"><span class="tmd-italic">reference value</span></span> terminologies are totally useless for Go, I just think they are not very essential, and they bring many confusions in using Go. If we do need these terminologies, I prefer to define them as pointer holders. And, my personal opinion is it is best to limit the <span class="tmd-bold"><span class="tmd-italic">reference</span></span> word to only representing relations between values by using it as a verb or a noun, and never use it as an adjective. This will avoid many confusions in learning, teaching and using Go.
</div>
<p></p>
</div>
